John DiMarco <fdd@cdf.toronto.edu> writes: > Surely there is a third way: time-lapsed full disclosure. When a problem is > discovered, don't announce it until there's a patch, then announce the problem > and the patch together, without exploitation information. > > After a suitable time (weeks?) has passed, the rest of the information can be > announced. But don't post scripts to exploit the bug; it gives root to too > many newbies. > > Announcing: "there's a problem here, go bug your vendor" isn't very helpful. > Announcing: "there's a problem here; here's how to use it to become root" is > dangerous, because you set up a race between sysadmins and hordes of newbies > all trying to exploit the bug before it is patched. I'd think of "time-lapsed full disclosure" as: 1) Bug is found and 8lgm and vendor(s) notified. 2) 8lgm posts notice of bug and any possible fix/workaround/patch if known. 3) After a few days for simple easy to fix bugs (i.e. chmod -s crash since non-sysadmins don't/won't need to run it anyway) up to maybe a month for more difficult bugs (kernel divide by zero gives root) a full explanation and exploit scripts are published. The only problem I see with this from my point of view is that when the exploit scripts are published, other systems may be found that are vulnerable that weren't known at the time. But I'd rather err on the side of too much information than too little. I suppose this would leave a role for the so-called "in crowd" like Gene Spafford -- they might get early access to the details and exploit scripts and could test other systems for the bug. If additional systems are found vulnerable those vendors could be notified as well and an update to the previous notice be posted. I side with those who would claim that Gene Spafford and his ilk should be forced to come up with evidence that full disclosure does NOT force bugs to be fixed faster, and that it DOES result in more breakins, rather than trying to put the burden of proof on the full disclosure crowd. You should be forced to provide a reason for restricting information, and information should flow freely otherwise. I see the need for trying to hold off on full details and exploit scripts the instant something is discovered, to keep complete idiots who know nothing from running the script and causing problems, but the wait time should be kept as short as possible so that any sysadmin who keeps up with Usenet, a list such as this, CERT advisories, or vendor patch info would have a reasonable chance at fixing this problem. If someone isn't keeping up, too bad for them. I don't want to suffer because they are lazy and/or overworked, neither are my problem. -- Doug Siebert dsiebert@isca.uiowa.edu